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Introduction 


This book discusses the next generation of robot explorers for the 
surface of the Earth, our Moon and Mars. Up to this point, surface 
exploration has used one or two car-sized vehicles, operating on 
their own, or perhaps just a drone. Mars exploration has involved 
one or two rovers covering a small area around a landing site. 


A paradigm ship in spacecraft architecture has been the Cubesat 
approach, a standardized, open source design. Cubesats have 
become more capable. The standardization of the hardware and 
software for Cubesats have made construction, testing, and 
operations easier and less expensive. 


The CubeRover concept came out of Carnegie-Mellon University's 
Robotics Group headed by the famed Red Whittaker, who lead the 
CMU team to win the DARPA Challenge. A second company, 
Astrobotics, was spun off to address NASA's challenge. 


Author 


The author received a Bachelors degree in Electrical Engineering 
from Carnegie-Mellon University, and Masters Degrees in Physics 
and Computer Science from the Johns Hopkins University. 


He was glued to the black & white TV for the launch of the 
Vanguard, the U. S.'s first satellite, through the Apollo missions. 


He began his career in Aerospace with Fairchild Industries on the 
ATS-6 (Applications Technology Satellite-6), program, a 
communication satellite that developed much of the technology for 
the later TDRSS (Tracking and Data Relay Satellite System). At 
Fairchild, Mr. Stakem made the amazing discovery that computers 
were put onboard the spacecraft. He quickly made himself the 
expert on their support. He followed the ATS-6 Program through 
its operation phase, and worked on other projects at NASA’s 


Goddard Space Flight Center including the Hubble Space 
Telescope, the International Ultraviolet Explorer (IUE), the Solar 
Maximum Mission (SMM), some of the Landsat missions, and 
others. He was posted to NASA’s Jet Propulsion Laboratory for the 
MARS-Jupiter-Saturn (MJS-77), which later became the Voyager 
mission. It is still operating and returning data from outside the 
solar system at this writing. 


Mr. Stakem is affiliated with the Whiting School of Engineering of 
the Johns Hopkins University. He recetved NASA's Space Shuttle 
Program Managers commendation award, as well as two NASA 
Group Achievement awards, the NASA Apollo-Soyuz Test 
Program Award, and a Certificate of Appreciation, NASA Earth 
Science Technology Office. Mr. Stakem has completed over 42 
NASA Certification Courses in various areas. 


He participated in two summer sessions of NASA/Goddard Space 
Flight Center's Engineering Bootcamp, bringing together student 
teams from the Western hemisphere to design, implement, test and 
deploy Grover, the Greenland Rover. Grover hosted an ice- 
penetrating radar to map the depth of the ice sheet. 


He also was responsible for 2 summer sessions of a Cubesat 
Project at Capital Technology University, involving teams from the 
Brazilian Scientific Mobility Program. During these sessions, the 
students pushed the technology for Cubesat and Cube-Xs. This 
resulted in numerous technical papers and presentations. 


Cubesats 


A Cubesat is a small, affordable satellite that can be developed and 
launched by college, high schools, grade schools, and even 
individuals. The specifications were developed by Academia in 
1999. The basic structure is a 10 centimeter cube, (volume of | 
liter) weighing less than 1.33 kilograms. This allows multiples of 
these standardized packages to be launched as secondary payloads 
on other missions. A Cubesat dispenser has been developed, the 


Poly-PicoSat Orbital Deployer, P-POD, that holds multiple 
Cubesats and dispenses them on orbit. They can also be launched 
from the Space Station, via a custom airlock. ESA, the United 
States, and Russia provide launch services. The Cubesat origin lies 
with Prof. Twiggs of Stanford University and was proposed as a 
vehicle to support hands-on university-level space education and 
opportunities for low-cost space access. This was at a presentation 
at the University Space Systems Symposium in Hawaii in 
November of 1999. 


Build costs can be lower than $10,000, with launch costs ranging 
around $100,000, a most cost-effective price for achieving orbit. 
The low orbits of the Cubesats insure eventual reentry into the 
atmosphere, so they do not contribute to the orbital debris problem. 


Central to the Cubesat concept is the standardization of the 
interface between the launch vehicle and the spacecraft, which 
allows developers to pool together for launch and so reduce costs 
and increase opportunities. As a university-led initiative, Cubesat 
developers have advocated many cost-saving mechanisms, namely: 


¢ Areduction in project management and quality assurance 
roles . 


* Use of student labor with expert oversight to design, build 
and test key subsystems. 


* Reliance on non-space-rated Commercial-Off-The-Shelf 
(COTS) components . 


¢ Limited or no built-in redundancy (often compensated for 
by the parallel development of Cubesats) . 


¢ Access to launch opportunities through standardized launch 
interfaces. 


¢ Use of amateur communication frequency bands and 
support from amateur ground stations. 


¢ Simplicity in design, architecture and objective . 


Multiple Cubes can be carried as secondary payloads on military 
and commercial flights, Cubesats, as small, inexpensive units have 
a higher mission risk tolerance. 


Since the initial proposal of the concept, further efforts have been 
made to define internal and external interfaces made by various 
developers of Cubesat subsystems, products, and services that have 
defined the Cubesat 'standard' as it is today. A core strength of the 
Cubesat is its recognition of the need for flexibility in the 
definition of standards, and since conception the standard has 
evolved to ensure that these design rules are as open as possible. 
The most significant of these further advances in definition have 
been for the POD systems (in order to meet launch requirements) 
and the modularization of the internal electronics. 


A simple Cubesat flight controller can be developed from a 
standard embedded computing platform such as the Arduino. The 
lack of radiation hardness can be balanced by the short on-orbit 
lifetime. The main drivers for a Cubesat flight computer are small 
size, small power consumption, wide functionality, and flexibility. 
In addition, a wide temperature range is desirable. The architecture 
should support a real time operating system, but, in the simplest 
case, a simple loop program with interrupt support can work. 


Another important and related aspect in the design approach is that 
of modularity in a complete and integrated Cubesat life cycle, 
effectively representing a modular system of systems. The 
accelerated life cycle demonstrated consistently by small satellites, 
and harnessed by many Cubesat developers, can be further 
enhanced by the application of modularity. 


The Cubesat Design Specification 
The Cubesat Design Specification, developed by California 


Polytechnic State University, defines the physical and interface 
specifications for Cubesats, and gives testing requirements for 


vibration, thermal-vacuum tests, and shock, as well as safety. Since 
a Cubesat flys with other Cubesats in a deployment device, and 
with a primary payload, safety is a concern. Cubesats are expected 
to have an on-orbit lifetime of less than 30 years. 


If your Cubesat is not going to Earth orbit, some of the restrictions 
can be waved. In addition, depending on the launch vehicle, some 
further restrictions may be removed. For instance, if you are 
sending multiple payloads to the moon, and the launch is your 
design, you can set the rules and requirements. 


Here is a synopsis of CubeSat requirements: These requirements 
were designed for Cubesat missions to Earth orbit, sharing a 
launch vehicle. Some elements might not be applicable to Cubesat 
dedicated missions to the lunar or Martian surface and beyond. 


Mass 
e Each satellite may not exceed 1 kg of mass 


e The CubeSat center of mass must be within 2 cm of the 
geometric center. 


Structure 


All edges contacting rails must be rounded. Cubesats must have at 
least 75% (85.125 mm of a possible 113.5 mm) of flat rail contact 
with the deployer- To prevent cold-welding, raw metal is not 
allowed as the contact surface of the bottom standoff. Derlin 
inserts, or a hard anodize are examples of acceptable contact 
surfaces. 


The outer surfaces of the CubeSats are required to be hard 
anodized in order to prevent wear between the sliding rails and the 
CubeSats. 


Separation springs 


(SSMD-51P recommended) must be included at designated contact 
points. A custom separation system may be used upon approval by 
CalPoly/Stanford launch personnel. 
One deployment switch is required (two are recommended) for 
each CubeSat. 


Material 


The use of Aluminum 7075 or 6061-T6 is suggested for the main 
structure. If other materials are used, the thermal expansion 
coefficient must be similar to that of Aluminum 7075-T3 (the POD 
material) and approved by CalPoly/Stanford personnel. 


Deployables 
A time delay, on the order of several minutes, must be present 
between release from the P-POD and any satellite hardware 


deployment, to allow for satellite separation. 


P-POD rails and walls cannot be used to constrain deployable 
hardware 


Communication 
There must be a time delay, on the order of several minutes to an 
hour, before all primary transmitters are activated. Low power 


beacon transmitters may be activated after deployment. 


Operators must provide proof of the appropriate license for 
frequency use. 


Power 
CubeSats with rechargeable batteries must have the capability to 


receive a transmitter shutdown command, compliant with FCC 
regulations. 


Satellites that require testing and battery charging must provide an 
external hardware interface to access the power/data port 


A 'remove before flight pin' is required to deactivate the CubeSats 
during integration outside the P-POD. The pin will be removed 
once the CubeSats are placed inside the P-POD. 


General 


Cubesats must be able to accommodate co-payload satellites with 
solar panels mounted on the external walls - A final check of 
specifications is conducted prior to launch. 


There are emerging standards for larger Cubesats, such as 6U (12 
kg, 12 x 24 x 36 cm), 12U (24 kg, 23 x 24 x 36 cm) and 27U (54 
kg, 34 x 35 x 36 cm). These allow acanister to constrain Cubesat 
deployables such as antennae and solar array. In the original 
Cubesat specification, this task had to be handled by the Cubesat 
itself. Even as they get bigger, the standard architecture and 
modularity of the Cubesat remains a game-changing advantage. 


For larger missions, we would use a mothership approach, which 
transports and deploys cubesats, and serves as a communications 
relay. The Mothership will have electronics in common with the 
explorer Cubesats. The mothership can also host a large cluster 
computer for in-situ data processing. In a water world scenario, the 
mothership could remain in orbit, deploying explorers as required. 
In a surface or sub-surface scenario, the mothership could deploy 
multiple explorers equipped for land and air mobility. 


Cube-x 


Cube-X is a concept derived from Cubesats. A Cube-X can be as 
simple as a Cubesat sitting on a mobility platform. “Cubesat” is 
taken here as a general concept for the electronics of a mobile 
sensor platform. A CubeRover is a Cube-X-architecture and a 
platform allowing it to explore. We are not limited to surface 
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exploration. The CubeRover can go underground to explore lava 
tubes, can go into oceans of the moons of the gas giants, or be 
deployed through the ice to explore that realm. In essence, the 
“Cube” past stays the same, and the sensors and mobility platform 
change as required by the mission and the environment. 


A Cube Rover has a standardized format, building on the proven 
Cubesat concept. A big player in the field is Astrobotic Technology 
at Carnegie Mellon University (the author's alma mater). The 
company received a NASA Small Business Innovation Research 
award to put a Rover on the Moon. An engineering prototype was 
built and tested successfully, and a flight-ready model is being 
constructed for launch in 2021. It will use the Company's Peregrin 
lunar lander. There is a spin-off Company called CubeRover, 
headquartered in Luxembourg. Astrobotics hopes to become a 
model for small planetary rover design. It has a contract with 
NASA to carry 14 payloads, including a rover, to the moon in 
2021, on its Peregrine launch vehicle. The rover is named Andy, 
after Mr. Carnegie. 


The rover Andy weighs in at 33 kg, and is 103 cm tall. It uses a 
four-wheel mobility system, and can achieve 18 cm/second. 


It will be delivered to the lunar surface by the Peregrine lander. It 
is 1.9 meters tall, and some 2.5 meters wide, with 4 deployable 
landing feet. It has a 90 kilogram payload capability, which may be 
increased after successful use. The mission will fly to the Moon on 
a commercial launch vehicle, such as a Space-X Falcon. The 
lander, which I will take the liberty of calling “Mothership” will 
communicate with the rovers via wifi. 


It's five engines 667 Newtons of thrust, and has an ability to 
achieve a delta-V of up to 3,250 meters per second. The fuel is 
monomethylhydrazine, “MMH” (CH3N2H;), with MON-25, a 
mixture of 75% nitrogen tetroxide and nitric oxide. These are 
hybergolic, and require no external ignition. The rover is 
generically called the MoonRanger. 
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Methods of Navigation 


Navigation in a structured environment is not a challenge. It's the 
real world that's a problem. A robot or spacecraft operates in a 
three-dimensional world, as do we. If they are not fixed, we need 
to measure a work-space's invariants, the dimensions, axes, 
possible navigation and reference points. A mobile robot can use 
dead reckoning or a beacon-based navigation. This works well on 
Earth, where we have navigation grid infrastructure such as GPS, 
but doesn't work on Mars. And Mars has no usable magnetic field. 
A key consideration for navigation is the choice of a coordinate 
system. For hundreds of years, Earth has had a well-defined 
latitude/longitude grid. There will be similar system for the Moon, 
and Mars. Navigation becomes obstacle avoidance when done up 
close. Neither the Moon or Mars yet has a satellite navigation 
system at the moment such as GPS. Using a variation of e-Loran, 
the mothership could serve as the reference point for navigation, 
and its position on the planet or moon self-determined from star 
and Sun positions, 


CubeRover housekeeping tasks 


Besides position determination and navigation, the onboard 
embedded systems have a variety of housekeeping tasks to attend 
to. 


Generally, there is a dedicated unit, sometimes referred to as the 
Command & Data Handler (C&DH) with interfaces with the 
spacecraft transmitters and receivers, the onboard data system, and 
the flight computer. The C&DH, itself a computer, is in charge of 
uplinked data (generally, commands), onboard data storage, and 
data transmission. The C&DH can send received commands 
directly to various spacecraft components, or can hold them for 
later dissemination at a specified time. The C&DH has a direct 
connection with the science instrument(s) for that data stream. If 
the science instrument package has multiple sensors, there may be 
a separate science C&DH (SC&DH) that consolidates the sensed 
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data, and hands it over to the C&DH for transmission to the 
ground. The C&DH can hand over all commands related to science 
instruments to the IC&DH. 


The computer calculates and maintains a table of consumables 
data, both value and usage rate. This includes available electrical 
power in the batteries, state-of-charge, the amount of thruster 
propellant (if any) remaining, and the status of any other renewable 
or consumable asset. This is periodically telemetered to the 
mothership, which keeps these data in a structured database. 


The electronics needs to be kept within a certain temperature for 
proper operation. Generally, the only heat source is the Sun, and 
the only heat sink is deep space. There are options as to how the 
spacecraft can be oriented. In close orbit to a planet, the planet may 
also represent a heat source. Automatic thermal louvers can be 
used to regulate the spacecraft internal temperature, if they are 
pointed to deep space. The flight computer's job is to keep the 
science instrument or communications antennae pointed in the 
right direction. This might be overridden in case the spacecraft is 
getting too hot or too cold. 


The computer needs to know the state-of-charge (SOC) of the 
batteries at all times, and whether current is flowing into or out of 
the batteries. It the SOC is getting too low, some operations must 
be suspended, so the solar panels or spacecraft itself can be re- 
oriented to maximize charging. In some cases, redundant 
equipment may be turned off, according to a predetermined 
electrical load-shedding algorithm. If the batteries are fully 
discharged, it is generally the end of the mission, because pointing 
to the Sun cannot be achieved, except by lucky accident. Don't bet 
on it. 


Communication relays are required to get data to earth. In some 
cases, Earth might not be visible to the lander, particularity if the 
Sun is in the way. In this case, the mothership stores the data in a 
structured database, and send it to Earth when communication is 


13 


restored. 


Onboard Software 


A robot is a special case of an embedded system. As such, it is 
generally more difficult to design, implement, and test. It must be 
treated carefully, because most of the CubesRover functionality 
will rely on software, and the mission success will be directly 
related to it's software. 


Software can be proprietary or Open Source, but almost all 
Cubesat onboard software is open source. 


Embedded software has several distinguishing characteristics: 


e There are no direct user interfaces such as monitor and 
keyboard. All interactions are through uplink and downlink. 


e It interfaces with numerous flight hardware devices such as 
thrusters, reaction wheels, star trackers, motors, science 
instruments, temperature sensors, etc. 


e It executes on _ radiation-hardened processors and 
microcontrollers that are relatively slow and memory- 
limited. 


e It performs real-time processing. It must satisfy numerous 
timing constraints (timed commands, periodic deadlines, 
async event response). Being late = being wrong. 


e Besides attitude determination and control, the onboard 
embedded systems has a variety of housekeeping tasks to 
attend to. 


NASA's Core Flight Executive, and Core Flight 
Software 


The Core Flight Executive, from the Flight Software Branch at 
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NASA/GSFC, is an open source operating system framework. The 
executive is a set of mission independent reusable software 
services and an operating environment. Within this architecture, 
various mission-specific applications can be hosted. The cFE 
focuses on the commonality of flight software. The Core Flight 
System (CFS) supplies libraries and applications. Much flight 
software legacy went into the concept of the cFE. It has gotten 
traction within the Goddard community, and is in use on many 
flight projects, simulators, and test beds (FlatSats) at multiple 
NASA centers, , as well as functioning in on-orbit Cubesat 


The cFE presents a layered architecture, starting with the bootstrap 
process, and including a real time operating system. At this level, a 
board support package is needed for the particular hardware in use. 
Many of these have been developed. At the OS abstraction level, a 
Platform support package is included. The cFE core comes next, 
with cFE libraries and specific mission libraries. Ap's habituate the 
Sin, or upper layer. The cFE strives to provide a platform and 
project independent run time environment. 


The boot process involves software to get things going after 
power-on, and is contained in non-volatile memory. cFE has boot 
loaders for the ARM, the Coldfire, and the Leon3 architecture. The 
real time operating systems can be any of a number of different 
open source or proprietary products, VxWorks and RTEMS for 
example. This layer provides interrupt handling, a scheduler, a file 
system, and interprocess communication. 


The Platform Support Package is an abstraction layer that allows 
the cFE to run a particular RTOS on a particular hardware 
platform. There is a PSP for desktop pc's for the cFE. The cFE 
Core includes a set of re-usable, mission independent services. It 
presents a standardized application Program Interface (API) to the 
programmer. A software bus architecture is provided for messaging 
between applications. 


The Event services at the core level provides an interface to send 
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asynchronous messages, telemetry. The cFE also provides time 
services. 


Aps include a Health and Safety Ap with a watchdog. A 
housekeeping AP for messages with the ground, data storage and 
file manager aps, a memory checker, a stored command processor, 
a scheduler, a check-summer, and a memory manager. Aps can be 
developed and added to the library with ease. 


CFE and its associated cFS are available as an architecture for 
Cubesats in general. 


The cFE has been released into the World-Wide Open Source 
community, and has found many applications outside of NASA. 


NASA's software Architecture Review Board reviewed the cFE in 
2011. They found it a well thought-out product that definitely met 
a NASA need. It was also seen to have the potential of becoming a 
dominant flight software architectural framework. The technology 
was seen to be mature. 


The cFS is the core flight software, a series of aps for generally 
useful tasks onboard the spacecraft. The cFS is a platform and 
project independent reusable software framework and set of 
reusable applications. This framework is used as the basis for the 
flight software for satellite data systems and instruments, but can 
be used on other embedded systems in general. More information 
on the cFS can be found at http://cfs.gsfc.nasa.gov/OSAL 


The OS Abstraction Layer (OSAL) project is a small software 
library that isolates the embedded software from the real time 
operating system. The OSAL provides an Application Program 
Interface (API) to an abstract real time operating system. This 
provides a way to develop one set of embedded application code 
that is independent of the operating system being used. It is a form 
of middleware. 
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cFS aps 


CFS aps are core Flight System (CFS) applications that are plug- 
in's to the Core Flight Executive (CFE) component. Some of these 
are discussed below. 


CCSDS File Delivery (CF) 

The CF application is used for transmitting and receiving files. To 
transfer files using CFDP, the CF application must communicate 
with a CFDP compliant peer. CF sends and receives file 
information and file-data in Protocol Data Units (PDUs) that are 
compliant with the CFDP standard protocol defined in the CCSDS 
727.0-B-4 Blue Book. The PDUs are transferred to and from the 
CF application via CCSDS packets on the cFE's software bus 
middleware. 


Limit check (LC) 

The LC application monitors telemetry data points in a cFS system 
and compares the values against predefined threshold limits. When 
a threshold condition is encountered, an event message is issued 
and a Relative Time Sequence (RTS) command script may be 
initiated to respond/react to the threshold violation. 


Checksum (CS) 

The CS application is used for for ensuring the integrity of onboard 
memory. CS calculates Cyclic Redundancy Checks (CRCs) on the 
different memory regions and compares the CRC values with a 
baseline value calculated at system start up. CS has the ability to 
ensure the integrity of cFE applications, cFE tables, the cFE core, 
the onboard operating system (OS), onboard EEPROM, as well as, 
any memory regions ("Memory") specified by the users. 


Stored Command (SC) 

The SC application allows a system to be autonomously 
commanded 24 hours a day using sequences of commands that are 
loaded to SC. Each command has a time tag associated with it, 
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permitting the command to be released for distribution at 
predetermined times. SC supports both Absolute Time tagged 
command Sequences (ATSs) as well as multiple Relative Time 
tagged command Sequences (RTSs). 


Scheduler (SCH) 

The SCH application provides a method of generating software bus 
messages at predetermined timing intervals. This allows the system 
to operate in a Time Division Multiplexed (TDM) fashion with 
deterministic behavior. The TDM major frame is defined by the 
Major Time Synchronization Signal used by the cFE TIME 
Services (typically 1 Hz). The Minor Frame timing (number of 
slots executed within each Major Frame) is also configurable. 


File Manager (FM) 

The FM application provides onboard file system management 
services by processing ground commands for copying, moving, 
and renaming files, decompressing files, creating directories, 
deleting files and directories, providing file and directory 
informational telemetry messages, and providing open file and 
directory listings. The FM requires use of the cFS application 
library. 


OpSys 


An operating system (OS) is a software program that manages 
computer hardware and software resources, and provides common 
services for execution of various application programs. Without an 
operating system, a user cannot run an application program on 
their computer, unless the application program is itself self- 
booting, and has an initiation module, that does the necessary 
hardware set-up. 


For hardware functions such as input, output, and memory 
allocation, the operating system acts as an intermediary between 
application programs and the computer hardware, although the 
application code is usually executed directly by the hardware and 
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will frequently call the OS or be interrupted by it. Operating 
systems are found on almost any device that contains a computer. 
The operating system functions need to be addressed by software 
(or possibly hardware), even if there is no entity that we can point 
to, called the Operating System. In simple, usually single-task 
programs, there might not be an operating system per se, but the 
functionality is still part of the overall software. 


An operating system manages computer resources, including: 


Memory. 

V/O. 

Interrupts. 
Tasks/processes/application programs. 
File system 

clock. 


The operating system arbitrates and enforces priorities. If there are 
not multiple software entities to arbitrate among, the job is simpler. 
An operating system can be off-the-shelf commercial or open 
source code, or the application software developer can decide to 
build his or her own. To avoid unnecessary reinvention of the 
wheel an available product is usually chosen. Operating systems 
are usually large and complex pieces of software. This is because 
they have to be generic in function, as the originator does not know 
what application space it will be used in. Operating systems for 
desktop/network/server application are not applicable for 
embedded applications. Mostly they are too large, having many 
components that will not be needed (such as the human interface), 
and they do not address the real-time requirements of the 
embedded domain. 


Adapting a commercial or open source operating system to a 
particular embedded domain can be tricky. Usually, the 
commercial operating systems need to be used “as-is” and the 
source code is not available. The software can usually be 
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configured between well-defined limits, but there will be no 
visibility of the internal workings. For the open source situation, 
there will be a multitude of source code modules and libraries that 
can be configured and customized, but the process is complex. The 
user can also write new modules in this case. 


Operating Systems designed for the desktop are not well suited for 
embedded use. These were developed under the assumption that 
whatever memory is required will be available, and hard deadlines 
required. 


Real-time operating systems, as opposed to those addressing 
desktop, tablet, and server applications, emphasize predictability 
and consistency rather than throughput and low latencies. 
Determinism is probably the most important feature in a real-time 
operating system. 


A microkernel operating system is ideally suited to embedded 
systems. It is slimmed down to include only those features needed, 
with no additional code. Barebones is the term sometimes used. 
The microkernel handles memory management, threads, and 
communication between processes. It has device drivers for only 
those devices present. The operating systems may have to be 
recompiled when new devices are added. A file system, if required, 
is run in user space. MINIX, as an example of a streamlined 
kernel, with about 6,000 lines of code. 


For computer systems like the Raspberry Pi, there are enough 
resources to run an operating system — in fact, it runs Linux. But 
linux is NOT a real time operating system. It can be patched to 
operate better in real-time applications, or a custom open source 
product such as FreeRTOS can be used. 


For Arduino-based boards, the architecture is just getting 
sophisticated enough to run an operating system. In many cases, an 
operating system is not needed. Keep in mind, that some operating 
system functions still need to be implemented. Setting up the 
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interrupt vectors at initialization is an example. The tasks that the 
computer has to do might be simple enough that a simple software 
loop architecture can do the job, perhaps with interrupts. 


File Systems 


Use of an industry-standard file system will ease the interface to 
ground based storage and processing. There are several popular file 
systems, usually defined as part of a specific operating system. A 
file system provides a way to organized your data, and file systems 
management services are part of the operating system. The 
operating systems may support several file formats. A file system 
organizes data. It presents a data-centric view of a digital storage 
system. 


A file is a container of information, usually stored as a one- 
dimensional array of bytes. Historically, the file format and the 
nature of the file system were driven by the mechanism of data 
storage. On early computer tape units for mainframes, the access 
mechanism was serial, leading to long access times. With disk and 
solid-state storage, the access time is vastly improved, as the 
device is random access — the same access time applies for any 
data item. 


Metadata includes information about the data in a file. This 
consists of the file name and type, and other parameters such as the 
size, date and time of creation, the data and time of last access, the 
owner and read/write/access permissions, when a backup was last 
made, and other related information. 


A directory, like the manila file folder, is a special file that points 
to (“contains”) other files. This allows files to be organized, and 
implements a hierarchical file system. 


There are many file system standards. The Microsoft operating 
systems support the FAT and NTFS file systems among others. The 
FAT (File Allocation System) format originated with early support 
of 8-bit microprocessor systems with MS-DOS. Fat-12 and FAT-16 
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had restrictions on the number of files in the root file system, but 
this has largely been removed with the introduction of FAT-32. File 
names are restricted to 8 characters, with a 3-character type 
specifier, the 8.3 format for file names. There are plenty of choices; 
don't re-invent the wheel. 


Attitude determination 


For the CubeRover on a surface, attitude determination is 
simplified over the on-orbit case. Since the CubeRover will be in 
touch with the surface, it really only needs to avoid tipping over, 
which may be fatal, or falling into a hole. If the unit is flying, or 
underwater, it will have to rely on the mothership as a reference 
point. 


Position determination 


Position determination on the surface cannot rely on magnetic field 
since they are almost non-existent for the Lunar and Martian cases. 
There is no equivalent of GPSS either. Navigation will be 
conducted by dead-reckoning along a per-determined path based 
on orbiters (LRO for the Moon, MRO for Mars). Local navigation, 
obstacle avoidance will be done optically. The current versions of 
the Raspberry Pi, for example, include dedicated image processing 
engines. 


A less sophisticated approach involves eLoran, an evolution from 
the original LORAN navigation system. It does not involve 
satellites. NIST is evaluating an eLoran chip starting with an SBIR 
in 2016. The eLoran is not as good (on Earth) as the in-place GPS, 
only supplying an accuracy of 8 meters. But it can supplement the 
GPS system. 


Electrical Power 


Electrical power is a critical resource. The power system of the 
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rover will consist of batteries, possibly solar cells for recharging, 
and a charge regulator. An explorer unit could be recharged from 
the mothership. In Earth orbit, the spacecraft is constantly moving 
from full sun to Earth shadow each orbit. The available energy in 
the batteries must be taken into account when planning operations. 
Big power users are RF transmission, and onboard computation. 


The latest generation of triple junction solar cells achieve up to 
30% efficiency in converting light to electrical power. The latest 
lithium-ion batteries are around 200 watt-hours per kilogram. 


A peak power tracker circuit serves as a “transformer” or 
impedance marcher between the solar arrays and_ the 
batteries/electrical loads, adjusting the impedance load the arrays 
“sees” for optimum transfer of power. It is a dc/de step down 
converter. 


Since Lava Tube explorers will, by definition, be operating 
underground, the opportunity for recharging is not available. The 
battery have to be sized to allow sufficient operating time. We 
might also envision a dedicated charger CubeRover that can 
recharge or recover and tow the Explorer CubeRover. 


Volcano Explorer 


The Robotics group at Carnegie-Mellon University is headed by 
the famed Red Whittaker, who lead the CMU team to win the 
DARPA Challenge. He also headed the team focused on the 
Google Lunar X Prize. One of his many projects was a mobile 
platform, Dante, designed to enter an active volcano. 


In December of 1992, Dante and his support team ventured to 
active Mount Erebus in Antarctica, 12,450 feet high, and about 800 
miles from the pole. Erebus is important enough that manned 
attempts were made to enter the caldera, all unsuccessful. How 
much the volcano contributes to the hole in the ozone layer above 
Antarctica is not known. The ozone layer blocks ultraviolet light 
from the sun, and is critical to the continuance of life on Earth. The 
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robot made the descent to the crater floor, some 850 feet from the 
top. Here it took temperature measurements, and gas samples. 
Erebus tends to erupt in a minor fashion several times a day. This 
was a NASA Project, supported by the National Science 
Foundation. The temperature proved to be around 1,100 degrees 
from the corrosive gases vented by the volcano. 


Dante is a six-legged walking robot, weighing close to 1000 
pounds, and connected to the support team outside the volcano by 
a tether to provide power and data, and possible retrieval if the 
robot becomes disabled. 


In August of 1994, an upgraded version of the robot, Dante 2, 
explored the active Alaskan volcano, Mount Spurr. This is located 
some 80 miles west of Anchorage. The descent into the caldera 
was 650 feet. The robot was monitored from a control facility in 
Anchorage, via a satellite link, providing a live video feed..lava 
tube 

-2 was bulked up at 1,700 pounds, having been redesigned based 
on the earlier robot's lessons-learned. It was able to explore 
underneath a rock ledge, that had blocked an aerial view of a part 
of the crater. After successfully completing its mission, the robot 
walked its way out of the crater. 


CMU Rovers have also been used in mine mapping. A rover called 
Groundhog went into an abandoned Pennsylvania coal mine and 
sent out live video to a conference on Mine Safety in 2002. The 
primary usage for the robots is seen as mapping. After initial tests, 
the concept of a wheeled rover was reconsidered, and an 
amphibious robot was designed. This is because old mines shafts 
are frequently flooded. 


Communications 


Communications can be via a tether, or radio. A tether is handy to 
supply power as well, but is a nuisance due to getting snagged. 
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Radio communications is a problem is there are numerous twists 
and turns n the path. Radio relays might be used, with the explorer 
dropping them as needed. Very low frequency radio has been 
shown to work through rock. Explorer units could drop relay units 
from their entry point, as they go along, but there necessarily a 
limit to the number of these that could be included. 


An approach to exploring lava tubes with CubeRovers. 


This section discusses an approach that evolved at a summer 
session of undergraduate and graduate students that the author 
mentored. It was a Cubesat-based program, so naturally the lava 
tube explorer was Cubesat-based. This is not a problem, as the 
Cubesat specification merely presents a standard architecture, just 
for Earth orbit. We can use them less restrictively at the Moon. For 
example, can use one in lunar orbit for a communications relay. 
Another Cubesat architecture and provide a __ lander 
vehicle/operations base. Individual explorers are essentially 
Cubesats with a mobility platform. The platform can be ground- 
based, with wheels, tracks, or legs. 


The project defined a fixed base on the lunar surface, with a 
mothership/carrier that served as a recharging station and data 
assembler and forwarder. This unit communicated with the orbiting 
communications Cubesat relay. The approach of using the Cubesat 
architecture for all the elements allows for an economy of scale, 
and an overall reduction in complexity. 


It also provides a commonality in architecture, and opens the 
possibility of implementation of a swarm-type cooperative 
behavior. Here, multiple co-operating units act together. This is not 
required for the Lunar mission, but can be useful elsewhere. 


Methods of Underground Navigation 
Navigation in a structured environment is not a challenge. It's the 


real world that's a problem. A telerobot operates in a three- 
dimensional world, as do we. If they are not fixed units, we need to 
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measure a workspace's invariant's, the dimensions, axes, possible 
navigation and reference points. A mobile robot can use dead 
reckoning or a beacon-based navigation. This works well on Earth, 
where we have navigation grid infrastructure such as GPS, but 
doesn't work on Mars. And Mars has no usable magnetic field. A 
key consideration for navigation is the choice of a coordinate 
system. For hundreds of years, Earth has had a well-defined 
latitude/longitude grid. There will be similar system set up for the 
Moon, and Mars. Navigation becomes obstacle avoidance when 
done up close. 


Loran is an older radio frequency navigation aid, using fixed 
beacons, circa 1957. As a supplement to space-based systems such 
as GPS, a variation called eLoran is being deployed. This approach 
would be feasible on other planets as well, with solar-powered 
beacons. 


On the surface, a rover vehicle with a camera can note the position 
of the Sun to get an idea where it is. Celestial navigation, using the 
“fixed” stars would also work. From the moon, the position of the 
Earth would help, and the rising and setting of Mars' two small 
moons would be useable. 


Once a lava tube is entered, the robotic vehicle must operate 
autonomously, due to the lack of a communications link. We might 
also consider radio relays withing the tube, but this gets complex 
fairly quickly. 


Lunabotics Mining Challenge 


NASA's Mining Competition was established in 2010, and is 
ongoing. It challenges college students to apply system 
engineering principles to mining scenarios, and test the hardware 
in the Caterpillar Mining Area. Schedule, Budget, and Design 
Philosophy are parameters for judging. NASA also required K-12 
outreach. There are a series of awards in different project areas. 
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Quoting from the announcement, “The Lunabotics Mining 
Competition is a university level competition designed to engage 
and retain students in Science, Technology, Engineering and Math 
(STEM). NASA will directly benefit from the competition by 
encouraging the development of innovative lunar excavation 
concepts from universities which may result in clever ideas and 
solutions that could be applied to an actual lunar excavation device 
or payload. The challenge is for students to design and build a 
remote controlled or autonomous excavator (lunabot) that can 
collect and deposit a minimum of 10 kg of lunar dirt within 15 
minutes. The complexities of the challenge include the abrasive 
characteristics of the lunar surface, the weight and size limitations 
of the lunabot, and the ability to control the lunabot from a remote 
control center. Twenty two teams from around the nation 
competed at the Kennedy Space Center Astronaut Hall of Fame 
These are annual events, with new teams selected each year. 


“The challenge will be conducted in a head-to-head format, in 
which the teams will be required to perform a competition attempt 
using the regolith sandbox and collector provided by NASA. 
NASA will fill the sandbox with simulated regolith, compact it and 
place rocks in it. Each competition attempt will occur sequentially. 
Between each competition attempt, the rocks will be removed, the 
regolith will be returned to a compacted state and the rocks will be 
returned to the sandbox. Consideration of prize awards will be 
based on each team's performance during the official competition 
attempt. All excavated mass deposited in the collector during the 
competition attempt will be weighed after completion of the 
competition attempt. The teams that excavate the first, second and 
third most lunar regolith mass over the minimum excavation 
requirement within the time limit will respectively win first, 
second and third place prizes.” 


The Moon Diver mission is currently going to use JPL's AXEL 
extreme-terrain rover. A good choice, as JPL is pretty much where 
to go for rovers to explore other planets. The JPL Open Source 
Rover is a non-flight design. It is based on the highly successful 
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Curiosity Rover. and uses a Raspberry Pi as a computer. It weighs 
about 25 pounds, and can move up to 9.7 inches per second. It uses 
the suspension design from Curiosity, and has 6-wheel steering. It 
is a non-flight unit, but incorporates a lot of good design and 
lessons learned from Mars operation. 


Spacebit is a U.K. Company, focused on space robotics. First 
launch is expected in 2021, of the lunar rover Asagumo (Japanese: 
morning spider) using Astrobotics Peregrine lunar lander. The 
spider will be one of 19 payloads going to the Moon on one 
launch. The spider has 4 legs, and hopes to get inside lunar lava 
tubes. 


Focusing on how the Spirit Rover got stuck on Mars, and ran out 
of power, JSC in Houston focused on a prototype Resource 
Prospector has more aggressive tires, on wheels that can lift. Each 
of the four wheels uses three motors. 


Robot Explorers on Mars 


Three nations, the United States, Russia, and India, have sent 
missions to study Mars. We will briefly mention those involving 
mobile units on the surface. 


The U.S. Viking mission in 1975 involved a surface lander, and 
associated orbiter, for imaging and communication relay. The 
Viking-2 lander was operational until 1978, and Viking-1 until 
1982. 


In 1997, the Mars pathfinder mission landed on the Martian 
surface, and deployed the rover, Sojourner. It was a platform with a 
six-wheel design, and controlled by an 8-bit processor. 


The Mars exploration rovers, Spirit and Opportunity were sent to 
the red planet in 2003. The MER are six-wheeled, 400 pound solar- 
powered robots, launched as part of NASA's ongoing Mars 
Exploration Program. Both used parachutes, a retro-rocket, and a 
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large airbag to land successfully, after transitioning the thin 
atmosphere of Mars. 


The MER are six-wheeled, 400 pound solar-powered robots, 
launched in 2003 as part of NASA's ongoing Mars Exploration 
Program. Opportunity (MER-B) landed successfully at Meridiani 
Planum on Mars on January 25, 2004, three weeks after its twin 
Spirit (MER-A) had landed on the other side of the planet. Both 
used parachutes, a retro-rocket, and a large airbag to land 
successfully, after transitioning the thin atmosphere of Mars. 


The Phoenix lander was launched in 2007, and landed on Mars in 
2008. Its mission ended in November of that year. It searched for 
microbial life, and to look for water. It completed its mission in 
August of 2008. After the Martian winter, the craft could not be 
contacted. It had a 90 day projected life on the surface, but 
exceeded this by 2 months. It could relay data to Earth via the 
orbiting Mars Odyssey, MRO, and ESA's Mars Express, part of 
Mars' in-situ infrastructure. 


Curiosity 


The Mars Science Laboratory (MSL) landed successfully on the 
Martian surface on August 6, 2012. It had been launched on 
November 26, 2011. It’s location on Mars is the Gale crater, and 
was a project of NASA’s Jet Propulsion Laboratory. It included a 
rover. 


The Rover vehicle Curiosity weights just about 1 ton (2,000 Ibs.) 
and is 10 feet long. It has autonomous navigation over the surface, 
and is expected to cover about 12 miles over the life of the 
mission. The platform uses six wheels The Rover Compute 
Elements are based on the BAE Systems’ RAD-750 CPU, rated at 
400 mips. Each computer has 256 Mbytes of RAM, and 2 Gbytes 
of flash memory. The power source for the rover is a radioisotope 
thermal power system providing both electricity and heat. It is 
rated at 125 electrical watts, and 2,000 thermal watts, at the 
beginning of the mission. The operating system is WindRiver’s 
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VxWorks real-time operating system. The vehicle was assembled 
and tested at NASA's Goddard Space Flight Center, and shipped to 
lead center JPL. The landing location in Gale Crater was named 
Bradbury Landing, after the science fiction writer, Ray Bradbury. 
Mars figured heavily in his writings. Gale Crater is named after an 
Australian amateur astronomer, Walter Gale. There is some 
evidence that the crater was once filled with water. 


The Insight Mission launched in May of 2018, and landed on Mars 
in November of that year. It is a robotic lander with a seismometer 
and a heat transfer probe. It is based on the Phoenix design. 


The mission landed near the Martian equator, which will provide 
maximum solar power during the 2-year mission. It touched down 
on the surface in November 2018, and continues to do science 
observations. 


The latest Mars surface exploration is coming up in 2021. It will 
include a Rover, which has a robotic helicopter. It will be an eye- 
in-the-sky, looking out for hazards, planning a path, and see things 
that the rover's camera can't. It will be autonomous in operation. It 
is a technology demonstration, planned to fly five times, during the 
early mission. The copter blades are a meter in diameter, and it has 
two counter-rotating sets. Compasses can't work on Mars due to 
the low magnetic field, so it will use solar tracking and inertial 
guidance. It will have its own solar panels. It is carried under the 
rover. It is dropped to the ground, and the rover moves some 
distance away so it can ascend. 


Swarms 


This section describes a different approach: collections of smaller 
co-operating systems that can combine their efforts and work as 
ad-ho teams on problems of interest. Cubesats can be organized in 
Swarms. 


This is based on the collective or parallel behavior of 
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homogeneous systems. This covers collective behavior, modeled 
on biological systems. Examples in nature include migrating birds, 
schooling fish, and herding sheep. A collective behavior emerges 
from interactions between members of the swarm, and the 
environment. The resources of the swarm are organized 
dynamically. 


Exploring planetary surfaces or lava tubes requires a diverse and 
agile system. Thus, a swarm of robotic spacecraft with different 
capabilities might be used, combining into Teams of Convenience 
to address situations and issues discovered in sit. 


Biological swarms, such as ants, achieve success by division of 
labor throughout the swarm, collaboration, and sheer numbers. 
They have redundancy, as any individual can do any task assigned 
to the swarm. The individual units are highly autonomous, but are 
dependent on other members for their needs. They achieve success 
with a simple neural architecture and primitive communications. 


In Swarm robotics, the key issues are communication between 
units, and cooperative behavior. The capability of individual units 
nodes not much matter; it is the strength in numbers. Ants and 
other social insects such as termites, wasps, and bees, are models 
for robot swarm behavior. Self-organizing behavior emerges from 
decentralized systems that interact with members of the group, and 
the environment. Swarm intelligence is an emerging field, and 
swarm robotics is in its infancy. Co-operative behavior, enabled by 
software and intro-unit communications has been demonstrated. 


We can postulate target selection according to mission goals, but 
also mention that mission goals change as data is collected at the 
site. The concept of multiple spacecraft/rovers coming together to 
form virtual instruments is discussed. Here, we might have 
simultaneous observations from multiple points. 


ANTS 
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Biological swarms, such as ants, achieve success by division of 
labor throughout the swarm, collaboration, and sheer numbers. 
They have redundancy, as any individual can do any task assigned 
to the swarm. The individual units are highly autonomous, but are 
dependent on other members for their needs. They achieve success 
with a simple neural architecture and primitive communications. 
NASA did a lot of work in the 1970's and 1980's on ANTS — the 
Autonomous Nano-Technology Swarm. The Basic concepts were 
defined, but the implementation was not yet ready. Now, Cube sat- 
type architectures can address that. Actually, ANTS was preceded 
by a Project called BEES, Biologically Inspired Engineering for 
Exploration Systems, as an architecture. The overall concept is 
many small units working together, self-configuring, self-healing, 
making in-situ decisions. No direct human control, not per- 
programmed, but agile, making decision on the spot. A reference 
mission to the Asteroid Belt in 2020 was defined. Well, here we 
are, where's the mission? (This is partially addressed in the authors 
book, “A Cubesat Swarm Approach for Exploration of the 
Asteroid Belt, originally a student project that got to a high TRL). 
Another feature the swarm exhibits is teaming, social interaction 
between individual units. ANTS was hard to implement with the 
hardware and software of the 1980's. It fits well into a Cubesat 
implementation. 


In Swarm robotics, the key issues are communication between 
units, and cooperative behavior. The capability of individual units 
nodes not much matter; it is the strength in numbers. Ants and 
other social insects such as termites, wasps, and bees, birds, fish, 
and reindeer are models for swarm behavior. Self-organizing 
behavior emerges from decentralized systems that interact with 
members of the group, and the environment. Swarm intelligence is 
an emerging field, and swarm robotics is in its infancy. Co- 
operative behavior, enabled by software and _ intro-unit 
communications has been demonstrated. 


We can postulate target selection according to mission goals, but 
also mention that mission goals change as data is collected at the 
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site. 


Ops concept. lunar explorer 


Once on the surface, the transporter can be imaged by orbital 
assets, and its position determined. This is the starting point for 
navigation. After that, keeping track of distance and turns, the 
location on the surface is known. Further sightings from orbit will 
update these data. 


With the caves or tubes located by in-orbit assets, the transporter 
vehicle will take the explorer vehicles to the entrance. A 
transporter, which uses a standard architecture. The transporter will 
stay at the mouth of the cave, and deploy an explorer. The 
transporter will run functional tests on the explorer before 
deployment, and ensure that it is fully functional. The transporter 
will also deploy a beacon at the cave mouth, to allow the explorer 
to find its way back. The transporter vehicle will not enter the 
caves. 


For navigation on the Lunar and Martian surface there is currently 
no GPS equivalent. Maps exist of the surface, based on orbital 
imaging. Dead reckoning could be used, and the two Martian 
moons are in stable orbits, so an hemispheric could be calculated. 
Then, by observation of their rising and falling, a position on the 
surface could be determined, not to a great accuracy. But, 
Columbus made it to America using a compass and an astrolabe 
for star positions. 


The ends of lava caves will be sought, to allow a horizontal entry. 
On the moon, due to the large angle of repose due to lower lunar 
gravity, the slope to enter the cave may be excessive. The 
property's of lunar regolith are fairly well known, due to 
snumerous amples returned by the Apollo missions. 


Another approach to entering the tube would be through the 
“skylight” at the top. These features are due to a partial collapse in 
the tube. The rover could be winched down into the tube by the 
transporter. Recovery of the unit will be problematic. These 
scenarios are being worked out and validated by field trials. 
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A similar approach would work for the Martian case. A slightly 
different approach would be needed for the Ocean-worlds like 
Callisto, Enceladus, Europa, Ganymede, and Titan and for Moons 
with an icy crust, with an ocean underneath. 


Viper rover 


NASA Ames' Viper rover is to be delivered to the lunar surface in 
2023. It's task is to search for usable resources, particularity water 
ice. It will support the follow-on crewed Artemis Mission. The 
mission and the hardware builds on the concept, Resource 
Prospector, which was canceled in 2018. 


It is unclear at the moment, whether the use of lunar resources is 
permitted under the 1967 Outer Space Treaty, signed by 92 
country's. The lawyers will work this out. 


Viper is heading to the lunar south pole, and is expected to operate 
for 100 days. The Russians, the Indian Space Research 
Organization, and U.S. Spacecraft have determined lunar water 
exists, especially in the shady sides of craters. Water is critical for 
lunar bases, and can be used as a source of oxygen. In addition, 
water can be broken down into hydrogen and oxygen, a rocket 
fuel. 


Viper has a drill, and three analyzers. The presence of water can be 
detected by the Neutron Spectrometer System at a distance. The 
rover will move to drill at this location, and use its onboard 
spectrometers to confirm the presence of water. 


Commercial Lunar Payload Services 
How are all those rovers going to the Moon? The answer is 
provided by NASA's Commercial Lunar Payload Services (CLPS) 


Program. NASA will contract for delivery to commercial 
providers. Flights are scheduled to begin in 2020. The first three 
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commercial lunar landers are Astrobotics Technology's Peregrine, 
Intuitive Machines Nova-C, and Orbit Beyond's Z-01/. 


NASA's Lunar Cargo Transportation and Landing by Soft 
Touchdown (Lunar Catalyst) Program defines putting exploration 
rovers on the Moon. NASA is assuming a cost of $1,000, 000 per 
kilo on the lunar surface initially. The price will come down with 
time, and experience will be gained with each flight. 


Peregrin 


The Peregrin lander, from Astrobotic in Pittsburgh is designed for 
lunar orbit and surface operations. It is almost 2 meters tall, and 
2.5 meters wide, with four landing feet. For its first mission, it will 
carry 90 kilograms of payload. It carry's 450 kg of fuel that is 
hypergolic, allowing for a 3,250 delta-V. It uses a doppler lidar for 
descent and landing. 


It's projected capability is 150kg to the lunar surface. It will fly as 
a secondary payload on a selected launch vehicle. There are 5 main 
engines, and 12 attitude control thrusters, arranged in clusters of 
three. The main engine thrust is 667 Newtons. Each ACS thruster 
has a thrust of 45 newtons. 


The lander has a solar panel to recharge the battery's. The flight 
computer is a rad-hard Leon-3, running GSFC's Core Flight 
Software, with a Xilinx FPGA-based payload CPU. There is an X- 
band link with Earth. On the vehicle, there are both hardwired and 
wireless communications. 


The vehicle can deliver payloads to lunar orbit, as well as to the 
surface. Payloads may remain attached to the vehicle, or can be 


deployed. 


Nova-C 
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Nova-C , from Intuitive Machines in Houston Texas, is expected to 
journey to the lunar surface with a boost from a Space-X Falcon-9 
in 2021. The spacecraft has its heritage from NASA's Project 
Morpheus. This was run out of the Johnson Space Center in 
Houston, and involved Armadillo Aerospace, of Dallas. The 
project kicked off in July, 2010. The first unit unfortunately 
crashed on take-off at the Kennedy Space Center. Other units were 
quickly built and tested. The engines use methane and oxygen. The 
Flight Software for the vehicle is NASA/GSFC's open source Core 
Flight Software. 


Astrobotics is also developing the Z-01 lunar rover. The Z-01 was 
influenced by Google X-Prize competitor Teamilndus, with 
partners including Honeybee Robotics, Advanced Space, and Ceres 
Robotics. Delivery dates are specified as 2020 and 2021. 


The company has said that will carry a total of 28 payloads on its 
maiden voyage. 


The company Orbit Beyond was in the selection of three 
company's, but has since dropped out. The Z-01 was derived from 
the Team Indus' HHK1 design. It has the capability to take 40kg to 
the lunar surface. The rover is the ECA, by Team Indus (Axiom 
Labs). It was expected to explore 500m beyond the landing site. It 
is a solar powered 4-wheeled design. It has stereo cameras and a 
sun sensor. It is expected to operate for a lunar day (14 days), and 
is not expected to survive the lunar night. 


Multi-rover support 


A satellite control center can handle a constellation, cluster, or 
swarm of multiple spacecraft. Examples include the GPS 
constellation, the weather satellite systems, TDRSS, and a number 
of commercial communications satellites, providing entertainment 
and data service world-wide. Constellations of communication 
satellites are used for commercial ventures such as DishNetwork, a 
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satellite TV provider, and Iridium and GlobalStar, communications 
constellations. 


Managing a Constellation adds to the complexity. Even if each unit 
is built to the same plan, different units still need customized 
attention. The most important aspect is to have a unique identifier, 
so you know which snit you're talking and listening to. 


An approach to Constellation control will involve a hierarchy of a 
master control center and multiple assets to control, or a peer 
network of individual control centers, that also provides a built-in 
redundancy and backup. 


An ongoing debate for the optimum architecture for multi-unit 
control is between a centralized design, and a distributed 
architecture. Centralized is the legacy approach. 


The distributed architecture scales more freely, with computation, 
storage, and communications resources being added as demand 
increases. High system reliability and security can be maintained 
from industry best practices. The scale-able, distributed technology 
is driven by large data-centric organizations such as Google, and 
retailers such as Amazon, as well as social media sites such as 
Facebook and Utube. These do not meet military-grade security, of 
course, but that can be addressed. 


Another advantage of the distributed approach is dynamic 
allocation of resources, having (and paying for) resources when 
you need them, not all the time. The system provides mission 
safety simultaneously with cost effectiveness. Distributed 
approaches give economy of scale. 


The same information for each unit in a homogeneous grouping 
provides summaries of critical cross-platform information. If we 
just had a failure on one spacecraft, we will look for that to happen 
on others. A merged database, allows for trending information to 
flow forward. As groups age, the individual members fail at 
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different rates. From trending data on early failures, the remaining 
group can be monitored especially for known failures and 
degradation. 


Several approaches will not only lower the cost of swarm 
approaches, but provide additional flexibility. As an example, the 
COSMOS open source control center product can handle multiple 
spacecraft simultaneously. It depends on the capabilities of the 
hosting hardware as to how many units can be supported 
simultaneously. That depends on the cpu and memory resources of 
the host. It is a scale-able approach. 


During a recent Cubesat Operations Course by the author, the 
concept of Control Center as a Service evolved. This means the 
control center software is hosted “in the cloud” much like Amazon 
or Gmail. Here, you pay for MIPS and Gbytes. The solution scales 
as you need it. If one node starts to get overwhelmed, you can 
dynamically add nodes. There is no Apollo-era Control room. 
Everything is on the web (with proper consideration for security, 
particularly for commands), and you access your units from your 
phone or tablet, anywhere. Amazon and Google will argue that 
their requirements for availability and security exceed that of a 
space mission. 


The students also explored the concept of a virtual operations 
controller. Standard control center software can text you when a 
value is at its yellow or red limits. We can expand that to look at 
combinations of telemetry points, and also have a rule-based 
program to examine the status. As the program evolves, and the 
software gets more capable (I hesitate to say, learns), the virtual 
ops controller can handle more of the routine monitoring and 
housekeeping tasks, and some of the upfront anomaly response. 
This involves an AI entity, a software agent, as a virtual flight 
controller. 
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Shared Databases 


Each member of the Group or Swarmwill be self-documenting. It 
will carry a copy of its Electronic Data Sheet (EDS) description, 
which can be updated. This defines the system architecture and 
capabilities, and has both fixed (as-built) and variable (what failed) 
entries. The main computer in the mothership has a copy of all of 
these, and can get updates by query. The Mothership also has 
parameters on each unit's state, such as electrical power remaining, 
temperature, etc. One value of the database is, if the mothership 
needs a unit with a high resolution imager, it knows what unit that 
is, and whether it has been deployed or not. If it has been deployed, 
it can query the unit on its position and health status. Implementing 
the EDS in a true database has advantages, since the position of the 
data item in the database also carries information. It also allows 
use of off-the-shelf database tools. The individual CubeSats have a 
“light-weight” database, while the mothership has a more 
sophisticated one. The Motherships' own EDS is also stored in its 
database. All the schema's are the same. 


The Mothership is responsible for aggregating all of the Cubesat's 
housekeeping and science data, and transmitting it back to Earth. 
This is also facilitated by the structure imposed by the database. An 
Open Source version of an SQL database is preferred. Sqlite is 
preferred for the Cubesats. The EDS documents could be in XML. 


The Control Center's command and telemetry will also be stored in 
a database. If a compatible architecture is used across the flight and 
ground units, major operational efficiencies can be shown. The 
control center will also host and share the units' EDS's. You can 
think of incoming telemetry, or you can think of database updates. 


Compute cluster of convenience 
Within the system, we can implement co-operative computing, 
with a goal of reducing downlink bandwidth to suite the 


capabilities of the system, while still returning information of 
value. This approach can be implemented with the Beowulf 
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software, and networking resources onboard the mothership. Each 
p-pod will supply power and a data link to the enclosed Cubesat. 
Each non-deployed Cubesat can participate in a Beowulf-class 
cluster computer. 


Using a variation of the Beowulf clustering software and the 
intranet of the Mothership, the Cubesats awaiting deployment can 
be linked into a Compute cluster configuration. Each will have the 
correct software to serve as a compute node pre-loaded as part of 
its Linux operating system. 


The Beowulf software was developed to provide a low cost 
solution to linking commodity pc's into a supercomputer. The 
approach has been applied to clusters of small architectures such as 
those that serve as flight computers for Cubesats. As part of the 
student summer cubesat program, we demonstrated a 5 node 
cluster, using Raspbery Pi's. Several 64-node clusters have been 
constructed. 


The Beowulf cluster is ideal to host software for sorting and 
classifying data; an example application is the Probabilistic Neural 
Network. This algorithm has been used to search for patterns in 
remotely sensed data. It is computationally intensive, but scales 
well across compute clusters. It was developed by the Adaptive 
Scientific Data Processing (ASDP) group at NASA/GSFC. The 
program is available in Java source code. 


The first Beowulf cluster to be flown in space was built from 20 
206-MHz StrongARM (SA1110) processors, and flew on the X- 
Sat, Singapore's first satellite. The performance was 4,000 MIPS. 
The cluster drew 25 watts. The satellite was a 100 kg unit, 80 CM 
cube. The cluster was used because the satellite collected large 
amounts of image data (80 GB per day), most of which was not 
relevant to the mission. The onboard classification algorithm 
selected which images would be downloaded. For example, cloudy 
images were discarded, since land images were of interest. The key 
concept demonstrated here was that the compute cluster could 
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reduce downlink requirements by pre-processing data in situ. 
Rad Hard Software 


The major problem for Spaceflight computers is radiation, 
although there are other environmental issues, and there can 
always be hardware and software residual errors that made it 
through testing. This becomes a much bigger problem during long 
cruise orbits to the outer planets, and for those planets with very 
large trapped particle fields. The RHS software approach will be 
flight software running on the Cubesats, and possibly on the main 
flight computer as well. This section explores an approach to detect 
and respond to pending radiation damage to flight computers. 


This approach is less expensive than flying radiation-hardened 
CPU's but does come with a risk. The Cubesat rad-hard compute 
architecture can be developed, but will be a more expensive 
approach. The software approach needs very thorough testing for 
validation. Even with Radiation hardened hardware, a “lighter” 
version of the rad-hard software would be a good approach. This 
provides Built-in self test. 


Rad Hard software is an approach that is software-based, and 
running on the system it is testing. From formal testing results, and 
with certain key engineering tools, we can come up with likely 
failure modes, and possible remediation's. Besides self-test, we can 
have cross-checking of systems. Not everything can be tested by 
the software, without some additional hardware. First we will 
discuss the engineering analysis that will help us define the 
possible hardware and software failure cases, and then we will 
discuss possible actions and remediation's. None is this is new, but 
the suggestion is to collect together best practices in the software 
testing area, develop a library of RHS routines, and get operational 
experience. These routines will be open source. 


Another advantage of the software approach is that we can change 
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it after launch, as more is learned, and conditions change. 


The RHS has many diverse pieces, and is not just one software 
module, but can be dispersed. Some of the RHS modules run 
continuously and some are triggered on demand, due to a specific 
event. It is desirable to have as much fault/failure coverage as 
possible, while minimizing the impact on the host's memory and 
timing. 


You're way ahead when you have some idea what is likely to fail, 
derived from testing, industry reports, and case studies. Fault 
coverage has to be as complete as possible, but we should ensure 
we have the known failure modes covered. Of course, some 
failures were missed in testing, resulting in their presence 
becoming known even in the operational environment. 


It is also critically important to know exactly what software has 
been loaded into the flight computer. What if you have multiple 
copies, and don't know which one is in use? Configuration Control 
prevents that, right? It has happened. 


There is also now a general policy of “test what you fly, fly what 
you test.” You might have included diagnostic code for integration 
testing, and pull it out before flight. Wrong. Now the code you are 
going to fly is untested. The tested version include the 
instrumentation code. Even though it will never be used, it takes up 
some space, so cache footprints, memory boundary's, and pipeline 
contents are different. 


We also need to carefully consider the failure recovery. Sometimes, 
we will need the system to reboot itself. That's disruptive, but 
necessary in some cases. We want to take every possible path 
before going down that one. 


The flight computers are operating in a hostile environment. There 


are known failure modes in this environment, that have to be 
covered. Failures will be transient or hard. Sometimes, hard 
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failures result in a state that is not recoverable. Transient failures, 
on the other hand, are the hardest to find. We can observe the 
results, and try to work backward to the root cause. That is where 
good up-front analysis and data from system test is invaluable. 
Some architectures, such as the ARM Cortex-R7 have built-in 
hardware failure detection. That's a good approach, but it leaves 
many potential failures uncovered. 


We can tap industry best practices code for system testing. We can 
also use testing code developed for system POST (power-on-self- 
test) as an example. POST is accomplished after a reset, but before 
the system begins to run operational code. It does allowed for 
checking internal functionality. POST should certainly be included 
in our repertoire. POST doesn't have specific run time 
requirements (except the annoyance threshold). A large block of 
memory can be tested in sections, to avoid adversely affecting 
system timing. 


Use of a common hardware bus and software architecture for all 
swarm members, to the greatest extent possible, is a goal. Only the 
sensor sets will be unique. A Cubesat model for the hardware, and 
NASA GSFC's Core Flight Software is baselined. A standard linux 
software operating environment and database will be used. 


Each group member will be equipped with one or more cameras, 
not only for target investigation, but also for observing the position 
and relative motions of other swarm members. 

Using standard linux clustering software (Beowulf), the 


Mothership and undeployed swarm members will be able to form 
an ad-hoc cluster computer to process science data in-situ. 


Surface Lander 


In the surface exploration scenario, a Cubesat-based architecture 
will serve as a local Mothership. It will be able to detach and 
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deploy the lander vehicle. An orbiting Cubesat can provide a 
“gods-eye” view, to target locations for direct exploration. It will 
also serve a a communications relay. The main problem will not be 
mobility, but rather avoiding floating off the surface. 


The ground-based unit will implement prox-ops in a more leisurely 
fashion, in that motion will be two-dimensional and at low speed. 
The surface rovers will not necessarily be retrieved. The local 
Mothership may be left at the observation site for additional data . 
The location of a lander/rover on the surface will be determined by 
the orbiting or station-keeping Mothership, with imaging. Standard 
space communications protocols will be used between the lander 
and the Mothership, via UHF link. 


The Cubesat members will collect observation data on their target, 
and can conduct radio occultation experiments to better categorize 
the distribution of particles. They can also conduct synchronized 
simultaneous observation from multiple observation points of 
features of interest. 


The Mothership is also an observer, with an instrument suite. 


ROS and other Open source software 


This section will discuss the software to be used on the explorers. 
It is, by choice, Open Source 


Besides the Linux operating system, most of the needed 
application software is also available open source 


Self-Check and Rad-Hard Software 


Built-in Fault Detection will be used on the surface rovers, both the 
transport and the explorer models. A secondary computer will 
continuously scan the onboard systems for emerging problems and 
faults. In some cases, the fault can be re-mediating by power- 
cycling, or switching in a redundant unit. Physical problems, like 
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jammed mechanisms might be fatal. Bigger picture, the fault 
detection system can monitor wheel rotation, and use the onboard 
inertial system to determine excessive tilt. 


On the surface, radiation is a problem. Rad Hard software is an 
approach that is software-based, and running on the system it is 
testing. From formal testing results, and with certain key 
engineering tools, we can come up with likely failure modes, and 
possible remediations. Besides self-test, we can have cross- 
checking of systems. Not everything can be tested by the software, 
without some additional hardware. First we will discuss the 
engineering analysis that will help us define the possible hardware 
and software failure cases, and then we will discuss possible 
actions and remediations. None of this is new, but the suggestion is 
to collect together best practices in the software testing area, 
develop a library of RHS routines, and get operational experience. 
These routines will be open source. 


Another advantage of the software-based approach is that we can 
change it after launch, as more is learned, and conditions change. 


This section explores an approach to detect and respond to pending 
radiation damage to flight computers. 


The RHS has many diverse pieces, and is not just one software 
module, but can be dispersed. Some of the RHS modules run 
continuously and some are triggered on demand, due to a specific 
event. It is desirable to have as much fault/failure coverage as 
possible, while minimizing the impact on the host's memory and 
timing. 


You're way ahead when you have some idea what is likely to fail, 
derived from testing, industry reports, and case studies. Fault 
coverage has to be as complete as possible, but we should ensure 
we have the known failure modes covered. Of course, some 
failures were missed in testing, resulting in their presence 
becoming known even in the operational environment. 
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Another approach is to use a dedicated rad-hard microcontroller 
(of the Arduino class) as a watchdog for a non-hardened processor, 
such as the ARM on the Raspberry Pi. The microcontroller could 
keep an electronic eye on all the computers in a cluster. 


Underground exploration sensor suite 


Such parameters as atmospheric pressure, temperature, light level, 
radiation detection, and such provide guidelines for a rover sensor 
suite. In addition, an odometer function provides distances 
traveled. For further details, we might deploy a ground penetrating 
radar on a rotation mount, so it could measure distance to the 
surface as well. GPR works well in dry materials and can detect 
changes in density up to 30 meters. Testing for gases would be a 
good idea, as would having the ability to sample the wall and floor 
material. A lidar unit could provide a 3-D map of the tube, but this 
puts additional strain on onboard computational and data storage 
resources. 


A stereo camera with changeable focus, and a video processing 
pipeline in the computer would be very useful. 


Afterword 


If we stop thinking about Cubesats as satellites, and apply their 
architecture to a variety of platforms, we can simplify complex 
exploration scenarios. We can literally use the same sensor 
platform with different domain packages. The top level concepts 
are the same, it is only necessarily to adaptive it to the 
environment. In a simple case, JPL is developing a Mars Rover 
that can launch a drone. If we were exploring an ice sheet, the 
drone might fly in front of the ground based rover to check for 
mission-ending crevasses. A lot of the hard work has been done, 
only requiring a few sharp software engineers to adaptive the 
design for different environments. 
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Glossary of terms and acronyms 


Actuator — device which converts a control signal to a mechanical 
action. 

A/D, ADC — analog to digital converter. 

ADCS -— attitude determination and control. 

ALHAT - Autonomous Landing Hazard Avoidance Technology. 

Analog — concerned with continuous values. 

Angle of repose — steepest angle of descent of a granular material. 

Aquafer — underground layer of water bearing permeable rock. 

AR&D — Autonomous Rendezvous and Docking. 

Artemis — (NASA) Program for next crewed lunar landing. 

ASIN — Amazon Standard Inventory Number 

Astro-speleology — study of caves on other planets. 

Async — asynchronous; 2 processes not sharing the same clock. 

AUV — autonomous underwater vehicle. 

Axel — JPL Rover. 

BAA — Broad Agency Announcement (U. S. Government) 

BIST — built-in self test. 

BRAILLE — (NASA) Biologic and Resource Analog Investigations 
in Low Light Environments. A cave explorer robot. 

Bus — data channel, communication pathway for data transfer. 

CAN — controller area network. 

CDR - critical design review. 

Chip — integrated circuit component. 

CLPS — Commercial Lunar Payload Services 

Clock — periodic timing signal to control and synchronize 
operations. 

Corrasional cave — form by flowing water along faults. 

COSMOS (Ball Brothers) Open Source Control Center Software. 

CPU — central processing unit. 

CRADA - Cooperative Research and Development Agreement (U. 
S. Government and industry) 

CSA — Canadian Space Agency. 

Cube-X — a small mobility platform, mounting a Cubesat-based 
hardware and software architecture. 

DALI — Development and Advancement of Lunar Instrumentation. 
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Delta-V — change in velocity 

Device driver — specific software to interface a peripheral to the 
operating system. 

Dissolution caves — caves formed by a liquid dissolving material. 

DOF — degree of freedom. 

DOI — digital object identifier. 

Droid — robot. 

DTM -— digital terrain model. 

EDAC ~— error detection and correction 

EDS — Electronic Data Sheet 

eLoran — enhanced Loran radio navigation system 

EMF — electro-magnetic field or force. 

EMI - Electro-Magnetic Interference. 

EOM -— end of mission. 

Ephemeris — position and velocity. 

Erosional caves — formed by flowing streams. 

ESA — European Space Agency. 

EXA — Agencia Espacial Civil Ecuatoriana, Ecuadorian Civilian 
Space Agency 

FPGA — field programmable gate array. 

Fracture cave — formed when soluble layers dissolve, leaving rock. 

FRR — flight readiness review. 

GEO — geosynchronous Earth orbit. 

Giga - 10? or 2°°. 

GHz — giga (109) hertz. 

GNC — guidance, navigation, and control. 

GNFIR - GSFC Natural Feature Image Recognition System. 

GNSS — Global Navigation Satellite System. 

GPR — ground penetrating radar. 

GPS — global positioning system 

Gray - unit of radiation, =100 rad 

GSFC — Goddard Space Flight Center, Greenbelt, Maryland. 
NASA Center for unmanned spacecraft near Earth. 

Helictite — speleothem that changed its axis multiple times during 
development. 

Hz — Hertz, or cycles per second. 

IAU — integrated avionics unit 
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IEEE — Institute of Electrical and Electronic Engineers. 
Professional organization and standards body. 

Intelsat = International Telecommunications Satellite Organization. 

Interrupt — an asynchronous event to signal a need for attention 
example: the phone rings). 

IP — Intellectual Property. 

IR — infrared, 1-400 terahertz. Perceived as heat. 

IRG — (NASA-Ames) Intelligent Robotics Group 

ISBN — International Standard Book Number. 

ISRS — In-space robotic servicing. 

ISRU — in-situ resource utilization. 

ISS — International Space Station. 

JPL — (NASA) Jet Propulsion Lab. 

KSC — (NASA) Kennedy Space Center. 

Lava Cave — a cave in volcanic rock 

Lavacicles — stalactite, grows down from the ceiling. 

Lava fan — a fan shaped structure of congealed lava, someimes at 
the openning of a lava tube. 

L-CIRiS — Lunar compact InfraRed Imaging System 

LETS — Linear Energy Transfer Spectrometer. 

LEXI — Lunar Environment heliospheric X-ray Imager. 

Lidar — light-based radar. 

LISTER — Lunar Instrumentation for Subsurface Thermal 
Exploration with Rapidity. 

LMS — Lunar Magneto-telluric Sounder. 

LOI — lunar orbit insertion. 

LOP-G — lunar orbiting platform — gateway. 

LORAN — World War -II era radio navigation system 

LRO — (NASA) Lunar Reconnaissance Orbiter. 

LSITP — (NASA) Lunar Surface and Instrumentation and 
Technology Payload. 

Lunar CATALYST — Lunar Cargo Transportation and Landing by 
Soft Touchdown. 

LuSEE — Lunar Surface Electromagnetics Experiment. 

LV — launch vehicle. 

MCC — mission control center. 

MCLSS - Mars Cave Life Support System. 
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Mineralogy — study of the physical property's of minerals. 

Minerogenesis — the formation of minerals. 

MMH — MonoMethylHydrazine. 

MRO — Mars Reconnaissance Orbiter. 

MSOLO — (KSC) Mass Spectrometer Observing Lunar Operations. 

NASREM - NASA/NBS Standard Reference Model for Telerobot 

Control System 

NASA - (USA) National Aeronautics and Space Administration 

NAVUS - NASA Autonomous Vehicle for In-situ Science. 

NBS - National Bureau of Standards, now NIST. 

NGLR — Next Generation Lunar Retroreflecrors. 

NIRVSS — (NASA-Ames) Near InfraRed Volatiles Spectrometer 

System. 

NIST — National Institutes of Standards and Technology. 

NOAA — National Oceanographic and Atmospheric 

Administration. (USA) 

NSC — (U.S.) National Space Council. 

NSS — neutron spectrometer system, on rover VIPER. 

Open source — methodology for hardware or software development 
with free distribution and access. 

ORU — Orbital Replacement Unit. 

PMCC — payload mission control center 

RAC — regolith Adherence Characterization 

Pahoehoe flows — surface moving lava. 

PDR — preliminary design review. 

PDU — payload data unit 

RCS — robot control system. 

Regolith — inorganic soil, mostly rocky, over bedrock. 

RFI — Request for Information. 

Rilles — troughs, possibly collapsed lava tubes. 

ROS — Robot Operating System (software) 

RRM - Robotic Refueling Mission. 

RSV — RESTORE Servicing Vehicle. 

RTG — radioisotope thermoelectric generator. 

RTOP - Research and Technology Objectives and Plans/ 

RTOS - real-time operating system. 

RWS — Robotic Work Station, on Space Station. 
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SAMPLR — Sample Acquisition Morphology Filtering, and 
Probing of Lunar Regolith. 

SBIR — Small Business Innovation Research. 

SCADA - Supervisory Control and Data Acquisition — for 
industrial control systems. 

Schema — organization of a data base 

Sensor — a device that converts a physical observable quantity or 
event to a signal. 

SELENE -— (Japan) Selenological and Engineering Explorer. 

Serial — bit by bit. 

SEU — single event upset. 

Stratigraphy — study of rock layers, sedimentary and volcanic. 

Skylight — partially collapsed ceiling in lava tube, providing an 
openning. 

SM - servicing mission. 

Solutional Cave — formed in soluble limestone. 

Speleothem — material formed in a limestone cave by deposition of 
minerals. 

Speleologists — Professional Cave explorer and scientist. 

Speleonauts — cave explorers in space. 

Spelunker — amateur cave explorer. 

SSN — (DARPA) sub-surface navigation. 

SSO — sun synchronous orbit 

Stalactite — grows down from the ceiling, and holds tight. 

Stalagmite — Might grow up due to dripping from stalactites. 

System — a collection of interacting elements and relationships 
with a specific behavior. 

System of Systems — a complex collection of systems with pooled 
resources. 

TDRSS — Tracking and Data Relay Satellite. 

Telerobot — a robotic system with a human in the loop. 

TLI — Trans-lunar injection 

Transceiver — receiver and transmitter in one box. 

TRIDENT — (Honeybee Robotics) — Regolith and Ice drill for 
exploring new terrain. 

USGS — United States Geological Society. 

VIPER — Volatiles Investigating Polar Exploration Rover. 
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VTVL - vertical take-off, vertical landing. 

Watchdog — hardware/software function to sanity check the 
hardware, software, and process; applies corrective action if 
a fault is detected; fail-safe mechanism. 
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